Set up npm release workflow for @onkernel/cua-cli - #28

Reviewed against release-cua-ai.yml / release-cua-agent.yml, ci.yml's cli-unit job, and the existing docs/npm-releases.md conventions. Verified locally from a clean checkout of this branch: npm ci, builds for cua-ai/cua-agent/cua-cli, cua-cli unit tests (29 passed, 4 skipped without the native binding), npm pack, actionlint on the new workflow (clean), and npm view for every pinned runtime dep (@onkernel/cua-ai@0.3.0, @onkernel/cua-agent@0.3.3, @onkernel/sdk@0.49.0, @earendil-works/*@0.79.1 — all published).

Workflow fidelity checks out: correct tag prefix and version-check path, tag-on-main guard, id-token: write, npm >= 11.5.1 for trusted publishing, zig/ptywright cache + install steps verbatim from ci.yml, dep-publish verification fails correctly on missing versions (E404 → xargs exit 123 → step failure), the smoke test invokes the installed bin rather than importing the module (required, since dist/cli.js runs main() on import), and publish can only fire on cua-cli/v* tags whose commit is on main. package.json metadata matches the packages/ai / packages/agent conventions; ptywright is dev-only and nothing under packages/cli/src imports it; the tarball contains dist + README.md only, with both smoke-test grep targets present in the help text.

Findings

1. (major) The manual first-publish runbook publishes a broken bin as of this branch. Reproduced: pack the tarball, install into a fresh project, ./node_modules/.bin/cua --help → ERR_MODULE_NOT_FOUND for dist/cli-harness (tsc under moduleResolution: Bundler emits extensionless relative specifiers that Node ESM rejects). The release workflow's smoke test guards tag-driven releases, but the "Releasing @onkernel/cua-cli 0.1.0" section has no equivalent check — a maintainer following it verbatim today ships a broken 0.1.0, and published npm versions are immutable. Fix within this PR's scope: add a pre-publish smoke step to the doc between steps 3 and 4 (npm pack --workspace @onkernel/cua-cli --pack-destination "$(mktemp -d)", npm install the tarball into a fresh temp project, run ./node_modules/.bin/cua --help), and state that the publish must not proceed until it passes. The underlying specifier fix (bundler build like tsdown, or explicit .js extensions in source) is rightly out of scope here, but the runbook must not green-light a publish before that lands. Relatedly, the PR body's "the smoke test is the safety net before any tarball goes to npm" only holds for the tag-driven path — the manual path this PR documents has no safety net.

2. (minor) package-lock.json wasn't regenerated for the packages/cli metadata change. The lockfile's packages/cli entry lacks the new license and engines fields (the packages/ai and packages/agent entries carry "license": "MIT"). npm ci still passes, but the next npm install anyone runs will dirty the lockfile with this PR's leftovers. Apply just the packages/cli entry update — note a full npm install --package-lock-only also picks up ~411 lines of pre-existing drift already present on main, which should stay out of this PR.

3. (nit) The doc's dependency note reads as exhaustive but isn't. It lists @onkernel/cua-ai, @onkernel/cua-agent, @onkernel/sdk as the runtime deps that must be on npm, but @earendil-works/pi-coding-agent and @earendil-works/pi-tui are also exact-pinned runtime deps (both published at 0.79.1). Either drop the parenthetical or make the list complete.

Scope is otherwise exactly right — three files, no source changes, and the judgment calls (30-minute timeout for the serialized native build, dual dep verification, verbatim ci.yml toolchain steps, specific usage-line greps) are all sound.